Traditional symmetric multiprocessing systems contain a system bus coupled to one or more processors, system memory and input/output ("I/O") devices (also referred to herein as bus devices). In order to fully support memory, cache and I/O coherency, the system bus employs "retry" protocols to maintain cache consistency. A "retry," which is sent by a bus device after it has snooped, or sampled, an address from the system bus placed there by one of the other bus devices, requires more time in order to determine whether or not a copy of the data represented by the snooped address is contained within an internal cache in a modified form; the retry is sent to the bus device that placed the address on the system bus in order to cause that bus device to again send that bus operation with that address onto the system bus at a later time, thus giving the snooping bus device time to make this determination. However, retry mechanisms typically reduce the overall system performance and add significant complexity to the chip and system designs.
Conventional systems perform cohereney with respect to attached I/O devices in the traditional sense that they provide coherency in much the same way processors provide coherency. When a processor accesses a cache line from system memory, it is the owner of that line and thus has to maintain a certain strict coherency protocol to keep the caches of other devices coherent. For example, if another processor attempts to access that line, the owner of the cache line has to indicate to others that it has that line, and may have to issue a retry. These certain specific rules for coherency can make system designs very cumbersome.
Certain blocks of memory may be cached in the processors or in input/output channel controllers ("IOCC"); both must be maintained as coherent, i.e., it is not desired to have a processor getting something from memory when it has been modified (incoherency). To have a cache within an IOCC means that all the protocols must be supported as they are for the processors. The challenge is that, unlike the processors, IOCCs have multiple asynchronous clocks. The processors have one clock so that they can do things real time. IOCC caches must stay coherent without necessarily working with all the ground rules of cache cohereney protocols.
Prior art techniques basically implement the afore-mentioned cache cohereney logic and run it in an IOCC just like a processor, so that whenever a microchannel master process wants to access data from memory, it is implemented as if a processor is trying to access something from memory. These microchannel masters appear like execution units to the system. They look like a processor with a fixed point unit, floating point unit, etc., reading and writing to memory. The problem with such a configuration is that with IOCCs, it requires a lot of hardware and complexity to maintain I/O coherency.
One of the problems with the asynchronous nature of the I/Os is that on the system bus, within a certain amount of cycles, an IOCC has to indicate whether or not it is going to retry, modify, rerun, etc. a bus operation. However, since in IOCCs the caches are located on the I/O bus side, communication between the system bus logic to the I/O bus logic required to determine whether or not the IOCC has the cache or not causes problems, since without a predefined fixed latency because of the two separate clocks, worse case designs or dual-ported arrays must be implemented.
With dual-ported cache arrays, whenever there is a snoop request that comes in off the system bus side, there is a separate port into the cache directories to implement a real time look up to maintain the fixed time delays of response. Thus, the directory runs the system clock time. With traditional IOCC structures having the actual caches in the I/O interface logic and not in the system interface logic, the IOCC will get a snoop and it will try to directory look-up real time without precisely knowing what is occurring. It just has this associative shadow directory that it is looking up at its clock speed. Therefore, it sometimes has to make some gross assumptions and may retry the system bus when it really did not need to.
As a result, there is a need in the art for a more efficient IOCC design so that degradation of operation of the system bus is not caused by traditional "retry" protocols.